導讀:背景轉轉作為一個初創公司,在成長過程中,面臨著大量的運營活動頁面以及MVp (Minimum Viable product,最小可執行產品)項目。這類項目技術上雖然沒有多復雜,但卻讓我們頭疼不已,主
發表日期:2020-07-08
文章編輯:興田科技
瀏覽次數:7316
標簽:
背景
轉轉作為一個初創公司,在成長過程中,面臨著大量的運營活動頁面以及MVp (Minimum Viable product,最小可執行產品)項目。這類項目技術上雖然沒有多復雜,但卻讓我們頭疼不已,主要有這幾個原因:
項目的這些特點,在前期給了我們很大的壓力。馬不停蹄的上線,頻繁的修改,技術的成長等,都讓我們有了一些疲憊。
后來,經過了半年的磨礪,漸漸的我們沉淀出了一些工具與經驗,來從容的應對這類型項目,先來看看我們的整體技術架構圖:
針對上圖我們仔細講解一下。
運營技術能力架構解讀
首先是通用需求模板,雖說這和前端技術沒太大關系,但實踐證明,協助產品整理出一個需求模板至關重要。因為項目著急時候,總是容易出現需求遺漏或不清晰的情況,如果后期修改的話,成本會很高。我們早期時候也總是會遇到遺漏埋點統計以和遺漏投放平臺的兼容性一類的需求。自從有了固定模板后,這類問題得到了根本的改善。
UI部分
我們使用photoshop作為主要的切圖工具,輔佐以Cutterman,借助其快捷的圖層和組操作,實現了切圖效率的提升。
業務技術部分
大部分運營類項目都有一定的模式,所以我們開發了一個組件化的頁面生成系統,取名“魔方”。這個系統可以支撐我們絕大部分運營類頁面的自動生成,運營人員可以使用魔方自己搭建個性化頁面,讓開發成本直接降到0,后面會重點講下這個系統。
除了相對較為標準的模板型頁面,我們也會碰到許多個性化運營頁面需求,對于這部分需求,我們做了以下工具/庫來保證業務的快速開發:
腳手架是我們得以快速開發的利器,現代前端開發越來越復雜,項目的前期搭建成本不低,一個好的種子項目(project-seed),可以讓開發的時候只需要關注核心業務,無需被繁瑣的配置干擾。
UI庫也是必需品,各個公司通常都會有一個自己的業務UI庫。可能封裝的不是那么完美,但一定能解決大部分業務問題。
終端ApI適配庫主要是解決頁面容器的接口統一問題,比如設置分享信息。微信/微博/手Q以及我們自己的App等都不一樣,需要有個庫來適配。
除了前端頁面部分,我們還使用了Nodejs開發部分業務的后端接口,實踐發現,針對某些后端邏輯較弱的業務,使用Noejs可以讓我們的效率得到很大的提升,這點后面我們也會具體講下。
組件化開發平臺
運營類項目應該優先使用模板生成,這已是一個業界的共識,剩下的問題就是如何開發一個頁面模板平臺了。組件化開發平臺如下圖所示:
UI相對簡陋,但功能還是很健全的。操作起來也很簡單,以組件為維度,運營人員添加/編輯組件,預覽無誤后,最后發布頁面,服務器會根據運營配置的信息,進行頁面的構建,最后把構建結果分發到相應的服務器,就實現了一個頁面的發布。
在前端組件化開發的大潮下,我們以組件為維度開發了這個平臺。
在我們看來,頁面就是由各個組件來組成,一個組件就像一個函數,它接收數據,返回頁面。運營人員在我們的平臺選擇組件,其行為類似于import一個包,然后編輯配置,也就是給組件傳入數據,當確定組件和數據之后,我們自然可以把組件渲染出來。
確定了組件的模式之后,隨之而來的第一個問題,便是組件的存儲形態。一個組件,它應該是一個JSX文件?還是一個NpM包?又或者其他?這個問題讓我們產生了糾結。
在經過了激烈的討論之后,我們最后決定使用NpM包來表述一個組件。依托于NpM完善的發布/拉取,以及版本控制機制,可以讓我們少做一些額外的工作,快速的把平臺搭建起來。當這點確定之后,我們的整個開發流程如下:
開發人員使用我們的組件腳手架來開發組件,一個組件通常包括UI顯示部分與配置部分,當開發完成時,便可以把組件發布在我們的私服npm上。進入魔方組件管理頁面,添加該組件,得益于Webpack的動態加載機制,運營人員在接下來的頁面設計中可以使用該組件。在魔方中新建一個頁面,添加我們剛剛更新的組件,然后進行一系列的配置。發布該頁面,魔方的后臺Server會根據配置信息,比如使用了哪些組件,每個組件的配置等,導出一個JSON文件。根據JSON文件,調用腳本,然后使用Webpack去構建出頁面,最后分發到服務器。因為是在服務端構建生成頁面,這樣也節省了用戶打開頁面時,拉取初始化配置信息接口的過程,大大減少了白屏時間。最后我們再看一看魔方系統的技術架構,如下圖:
這是我們系統目前架構圖,支撐了我們部分運營類型頁面,由組件為核心,一方面組件和UI庫打通,另一方面配置部分導出ApI,可以提供給其余端用(小程序、RN、客戶端等)。然后魔方平臺通過CNpM拉取組件,給運營人員提供一個可視化頁面編輯平臺。
魔方系統我們還在不斷的迭代中,它肯定有很多設計不好的地方,十分歡迎大家一起來討論。
Nodejs中間層
現在越來越多的公司使用Nodejs,目的各異。我們也使用了Nodejs,其中一個目的在于提高個性化運營項目的開發效率。我們大部分運營項目,對于后端的需求并不高。通常是做一些簡單的存儲和調用一下底層的服務,比如領紅包,抽獎,查詢商品等。這些服務都有成熟的底層接口,所以在應用層來說,邏輯就十分的少了。RD來做的話,可能半天一天開發完了,但是要花更多的時間在需求評審溝通,測試上線驗收等階段,十分浪費時間。如果這部分邏輯如果交由FE用Nodejs實現,可以有效減少溝通聯調時間,更重要的是節省了人力。我們項目后端使用的是JAVA,所以這里我們做了一層Nodejs中間層,來實現了Nodejs與Java的互通。
關于Nodejs和Java交互方式,我們之前寫過一篇文章,感興趣可以看看實戰系列之Node.js玩轉Java
前端監控
運營類項目追求效率,這樣很容易導致質量不佳。前期我們往往把質量完全寄托于QA的把關以及開發人員的技術水平,但長遠來看,線上頁面的監控也是一個不可或缺的角色。
監控主要有兩方面:
性能監控能很好的幫我們把關頁面的性能,轉轉FE支撐團隊研發了一套性能監控系統。以插件的形式,在入口文件引入后,會通過高階組件形式,Hook頁面組件的生命周期。通過performance ApI,獲得各個階段的數據,通過埋點的方式,向后臺發送數據,并展示。
異常監控部分,以Webpack插件的形式,在生成HTML的時候,給代碼加上錯誤監控sdk,并格式化錯誤信息,發送給后臺展示。原理是使用window.onerror監聽頁面的錯誤。這里面也會需要處理一些問題,比如跨域script的錯誤捕捉,壓縮代碼使用sourcemap的還原等。
后記
以上這些就是我們高效開發運營類活動的經驗了。對于成熟的公司來說,這些系統可能很早就有了,并且十分強大。但對于轉轉來說,一切還需要我們根據實際業務一步步完善。
效率是一個永恒的話題,下個階段,我們會針對更多元化的頁面(比如動畫類),去找出它們的通用點,沉淀下來,讓我們的效率得到更高的提升,也歡迎大家一起來交流。
作者簡介:
黃家興,轉轉前端運營組負責人。
上一篇:
暫無信息更多新聞
2020
關于網站建設,企業網站的作用更類似于企業在報紙和電視上所做的宣傳企業本身及品牌的廣告。不同之處在于企業網站容量更大,企業可以把任何想讓客戶及公
View details
2020
關于網站建設,當搜索引擎的算法改變或者加強時,導致一些網站的某些關鍵字排名消失,一些管理員就說他們的網站消失了。實際上并非如此,在搜索引擎算法改變
View details
2020
關于網站建設,總有很多人問我百度怎么了?有什么變化,為什么不更新等等諸如此類的問題。不論是否百度做過算法調整,或許只要因為某些事情百度不更新,也會有
View details
2020
關于網站建設,科技是第一生產力,信息時代是技術的時代。誰主導了技術,誰就主導著未來社會的發展。到這里,應該說這些結論都有道理。但由于信息技術的代表
View details